These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `dip-decentralized-masternode-shares.md`:
- [BLOCKING] dip-decentralized-masternode-shares.md:514-516: `sharesWithoutJoinSigs` serialization is ambiguous and consensus-critical
  The text says `sharesWithoutJoinSigs` is the concatenation of every CollateralShare with the `joinSig` field `omitted (treated as a zero-length byte string)`. Two reasonable readings produce different byte sequences and therefore different SharedRegConsentHash values:

  1. The `joinSig` field is omitted entirely — no bytes at all in the concatenation.
  2. The `joinSig` field is serialized as a zero-length compact-size bytestring — i.e., the single byte `0x00` (compact-size length 0, followed by no payload bytes), preserving the field's framing.

  `CollateralShare` (line 339) defines `joinSig` as `vector<unsigned char>  (compact-size length-prefixed, ...)`, which makes interpretation (2) the natural literal reading of `serialize(share)` with an empty vector — yet the word `omitted` suggests (1). Because every participant signs this digest and consensus recomputes it to verify `joinSig`, divergent implementations would either reject otherwise-valid v5 registrations or, once one implementation is patched, cause a chain split. The DIP must pin one encoding normatively and ideally show pseudocode (e.g., `serialize(share) with joinSig replaced by compact_size(0)` vs. `serialize(share) skipping the joinSig field entirely`).
- [BLOCKING] dip-decentralized-masternode-shares.md:573-636: ProUpShareTx and ProUpSharedRegTx digests sign nLockTime without binding input sequences
  The registration digest (line 468) commits to `sequencesHash`, and the dissolution digest (line 775) explicitly commits to `tx.vin[0].nSequence`; in both cases the DIP states the reason is to stop a coordinator/fee-payer from changing finality, RBF, or `nLockTime` semantics after participants sign (lines 500–504, 783–787). The ProUpShareTx digest (lines 573–580) and the ProUpSharedRegTx digest (lines 628–636) commit only to `inputsHash`, `tx.nLockTime`, and `tx.nVersion`/`tx.nType`; they bind no input `nSequence`.

  Because `nLockTime` is only enforced when at least one input has a non-final sequence, a party that controls or replaces the funding input signatures (which need not be SIGHASH_ALL/AC-payable in a way that commits to sequences) can flip an input to a final sequence after the participant signs, effectively neutralising the signed `nLockTime` (e.g., causing a future-dated reward-script update or shared-registrar update to take effect immediately). The risk is particularly acute for ProUpSharedRegTx, where every participant signs but a separate broadcaster/fee-payer typically supplies the funding inputs.

  Mirror the registration/dissolution model by adding `sequencesHash` (or an enumerated commitment to each input's `nSequence`) to both update digests, or — if the omission is deliberate because these updates do not bind finality — add a normative one-line note explaining why and remove `nLockTime` from these digests so implementers do not believe the spec enforces something it does not.
- [BLOCKING] dip-decentralized-masternode-shares.md:111-116: Provider payload versioning conflicts with the referenced DIP-0026
  This draft normatively claims `DIP-0026 introduces provider transaction payload version 4 (MultiPayout)` and then allocates `SharedCollateral = 5` for v5. The DIP-0026 document checked into this repository (`dip-0026.md` line 46) says it introduces `version 2` of ProRegTx/ProUpRegTx with `payoutShares`/`payoutSharesSize`, and makes no claim about versions 3 or 4. As a result, implementers reading only the merged DIPs cannot determine whether DIP-0026 is v2 or v4, what occupies version 3, or whether `SharedCollateral` should actually be version 3 (next free after DIP-0026) rather than version 5.

  The provider payload version is a consensus selector, so this is the kind of registry mismatch the review guidance flags as blocking. Either amend DIP-0026 in this repo to match (renumber its payload to v4 and reserve v3 / specify what it is), or change this DIP's version allocation to be consistent with DIP-0026 as merged. The 'Open Issues' section does not currently cover this dependency, so add it there or in 'Relationship to DIP-0026' with the resolution path.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `dip-decentralized-masternode-shares.md`:
- [BLOCKING] dip-decentralized-masternode-shares.md:957-961: Define "active v5 masternode" to include PoSe-banned registrations
  The active-set definition keys the mempool and block-level covenant rejection on "every collateral outpoint recorded against an active v5 masternode in the deterministic masternode list", but "active" is not defined. DIP-0003 distinguishes the registered set from the valid (non-PoSe-banned) subset, and an implementer reasonably reading "active" as "valid" would exclude PoSe-banned v5 masternodes from the active set. Mempool rule 1 (line 985) and block-connection rule 2 (line 994-1000) then would not reject an ordinary spend of a PoSe-banned v5 masternode's shared collateral, even though the later list-removal rule 4 (line 1009-1016) says any v5 masternode must only be removed by ProDisTx. That mismatch means a PoSe-banned masternode could be removed via collateral spend on one implementation and rejected on another — a consensus split. Same ambiguity affects the parallel summary at lines 264-269 and references to "active v5 masternode" at lines 1455, 1458, 1476. Specify that the protected active set is every registered v5 masternode in the deterministic list, including PoSe-banned ones, then propagate the wording consistently.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `dip-decentralized-masternode-shares.md`:
- [BLOCKING] dip-decentralized-masternode-shares.md:817-818: Early-period formula and prose disagree on the size of the early window
  The terminology entry at line 150 defines the early period as 'The window of `earlyPeriodBlocks` blocks after registration during which `earlyPenalty` applies.' The consensus formula at line 817 is `early = (H - state.nRegisteredHeight) < state.earlyPeriodBlocks`. However, same-block dissolution is explicitly forbidden (lines 925-936, 1302-1310, 1465-1471), so the first connectable `ProDisTx` is at `H = state.nRegisteredHeight + 1`. With the strict `<` test, the early-penalty regime then covers `earlyPeriodBlocks - 1` eligible blocks rather than `earlyPeriodBlocks`, and the edge case `earlyPeriodBlocks == 1` covers zero eligible blocks despite the prose promising a one-block window. Because `penalty` directly sets the consensus-required non-actor refund amounts and the actor's maximum output (lines 1421-1432), an implementer who follows the prose (`H - nRegisteredHeight <= earlyPeriodBlocks` or counts the natural N blocks after registration) will accept different `ProDisTx` outputs than one who follows the formula. Pick one semantics and align both the prose and the formula (and document the `earlyPeriodBlocks == 0` and `== 1` degenerate cases) before activation.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `dip-decentralized-masternode-shares.md`:
- [SUGGESTION] dip-decentralized-masternode-shares.md:1498-1499: Reorg test #4 wording conflicts with the update-target-must-exist rule
  Test 4 states that replaying a `ProUpSharedRegTx` followed by a `ProDisTx` 'in a different order' produces the same final state. Read literally, swapping the order places the `ProDisTx` first, which under the normative rules at lines 615-616 (the masternode identified by `proTxHash` MUST exist and MUST be a v5 masternode) and the dissolution-removes-the-entry semantics makes the later `ProUpSharedRegTx` invalid because the masternode no longer exists. The intent appears to be disconnect/reconnect determinism along the original chain order, not a branch with reversed transaction ordering. Tighten the wording so implementers do not infer that order-swapped reorg branches must converge.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `dip-decentralized-masternode-shares.md`:
- [SUGGESTION] dip-decentralized-masternode-shares.md:386: Specify on-wire framing for the share vector
  The v5 ProRegTx layout claims to be exhaustive and normative for `nVersion == 5`, but the `shares` row only says `CollateralShare[]` without naming the vector's length prefix. Every other vector in this DIP — `refundScript`, `rewardScript`, `joinSig`, and `vchSigs` — explicitly calls out `compact-size length-prefixed`, and the registration consent digest separately uses `LE8(shares.size())`. A reader synthesising the payload framing from those two sources alone could plausibly serialize the outer count as either CompactSize or LE8. CompactSize is the Dash/Bitcoin convention for top-level vectors, but the asymmetry with neighbouring vector fields is the kind of ambiguity the spec elsewhere takes care to remove. Add an explicit `sharesSize` row (or an inline note that `CollateralShare[]` is a CompactSize-prefixed vector) so the byte boundary preceding `earlyPeriodBlocks` is unambiguous.
- [SUGGESTION] dip-decentralized-masternode-shares.md:1070-1079: Assign the share-vector state-diff bit or mark it as a pre-activation open item
  This clause makes the share-vector diff encoding normative (full replacement is the single canonical representation), but it only says the state-diff bitfield 'gains a new field bit' without assigning the bit value. The state-diff bitfield is a consensus selector for how serialized deterministic-MN state diffs are decoded, so leaving the value unspecified prevents implementers from independently producing interoperable snapshots and reorg-replay payloads. The Open Issues section (line 1634) already enumerates other pre-activation deferred items (SHARED_MIN_SHARE_DUFFS, activation deployment name) — either assign the exact bit value here or add an explicit entry to Open Issues so the gap is tracked.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Duplicate comments:
In `@dip-decentralized-masternode-shares.md`:
- Around line 45-67: The document contains hardcoded references to DIP-0026 v4,
but the actual dip-0026.md file describes the multi-payout payload as version 2,
creating conflicting version contracts for readers. Locate all instances where
DIP-0026 is referenced with a version number in
dip-decentralized-masternode-shares.md (including the sections around lines
45-67 and 115-123 as indicated in the comment), verify the correct version from
the dip-0026.md file in the branch, and update all version references to match
consistently so readers have a single authoritative version contract to
implement against.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `dip-decentralized-masternode-shares.md`:
- [BLOCKING] dip-decentralized-masternode-shares.md:223-244: Discriminator byte position must be reserved by DIP-0026 v4 or moved to its own payload version
  This section makes `isSharedCollateral` a `uint8_t` placed in the v4 ProRegTx payload after `nMode` (Section 5.6 confirms the position at line 428-429), and then states that `isSharedCollateral == 0x00` payloads `follow the unchanged DIP-0026 multi-payout layout` (line 232-236) and `deserialize and validate exactly as DIP-0026 specifies` (line 1330-1333). DIP-0026 v4 is itself a pending/unmerged dependency (acknowledged at line 168 as the `pending DIP-0026 v4 design`), and nothing in this DIP or in the current repository copy of DIP-0026 records that DIP-0026 v4 reserves a discriminator byte at that position. As written, a shared-mode parser consumes one byte after `nMode` to select the variant, while a DIP-0026 v4 non-shared parser would treat that same byte as the first byte of `collateralOutpoint.hash`. The two parsers therefore frame the same v4 bytes differently, which shifts the rest of the payload for non-shared v4 registrations, invalidates payload hashes/signatures across implementations, and turns valid external-collateral hashes that happen to begin with a byte other than `0x00` into illegal discriminator values. Before activation, either DIP-0026 v4 must explicitly reserve this discriminator byte at the same wire offset for all v4 ProRegTx payloads (and that coordination must be called out here as an unresolved cross-DIP dependency in `Open Issues`), or shared collateral must be carried by a distinct provider payload version so the wire-format selector is unambiguous. The current `Open Issues` section does not list this coordination, and the rationale at line 1317-1333 argues against a separate version without addressing the framing prerequisite.